The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not necessarily prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In relational database management systems, information is stored in tables where each data item is stored at a particular row and column. In general, all of the information in a given row is associated with a particular object, and all of the information in a given column relates to a particular category of information. For example, each row of a table may correspond to a particular employee, and the various columns of the table may correspond to employee names, employee social security numbers, and employee salaries.
An application retrieves information from and updates a database by submitting queries to a database management system (DBMS). The DBMS processes the queries by retrieving the information and performing the updates specified in the queries. A series of queries or statements submitted to the DBMS for sequential execution is referred to as a transaction.
A database is a “versioned database” if it stores multiple versions of a given resource. For example, a versioned database may store multiple versions of a document. Most documents in the real world change over time. It is becoming increasingly important to keep a record of these changes, as this allows accessing an older version, determining who made each change, and tracking the progression of changes to the document. Thus, a versioned database not only provides a way to access document contents at important checkpoints but also allows users to track changes to a document.
Certain values within a document do not change from version to version. For example, an employee's ID typically does not change from year to year, but the employee record may need to be updated annually. Since each version of the employee record may need to be indexed and accessed as a separate entity, each version of the employee record is stored in a separate row of the table. However, this may lead to a uniqueness constraint problem when the value that is unchanged belongs to a constrained column.
A conventional uniqueness constraint prohibits two or more rows of a table from having the same value in a constrained column or group of columns. A database system will typically raise a uniqueness constraint violation if an application accessing the database attempts to perform an operation that causes two rows in a column under a uniqueness constraint to have the same value.
Some systems handle uniqueness constraint problems by storing older versions in a separate table (or other physical structure), hence ensuring that only one row in each version history is present in the table that has the constrained column. But this is based on the assumption that only one view (or label) of the table, typically the one showing the latest version, is needed. However, this assumption is not correct in many use cases.
Other systems may allow different versions to exist in the same table, and ensure that the uniqueness constraint is not violated in each registered view. However, using registered views is very expensive and inefficient.
Hence, there is a need to efficiently support uniqueness constraints when multiple versions of a resource are stored as different rows of a table. Note that, although this problem has been explained in the context of documents, it is equally applicable to relational rows that are versioned in a similar way.